In the early days of computers, virtually all computer systems consisted of stand-alone host processors to which peripheral devices (such as terminals, printers, disk drives, and the like) were connected, either directly or remotely through device controllers. Each host processor operated substantially independently and communications between different host processors were minimal.
It was recognized even then that computer users can benefit greatly by connecting host processors in networks. Such networks permit one or more users in different locations to send data to a single host processor. The single host processor can merge and process the data. The host processor can pass the data on to still other host processors or can use it in reports to be electronically distributed to users at locations remote from the host processor. Such networks also support company-wide electronic mail systems or even distributed processing operations in which host processors at different locations work together to execute what an outside observer would view as a single computer program.
Different suppliers of computer hardware and software developed different ideas of the formats and protocols that should be following in transporting data through networks. For example, some have developed protocols under which expedited data can be sent by bypassing normal data flow controls. Other protocols don't support expedited data flows. Different protocols also exist for such transport tasks as establishing and terminating connections between host processors.
Examples of well known communication protocols include System Network Architecture (SNA), Digital Network Architecture (DECnet), Transmission Control Protocol/Internet Protocol (TCP/IP), NetBIOS, OSI. Other communication protocols exist and are widely used.
The data to be transported through a network is, of course, generated by a computer program which is being executed on a host. Such computer programs are called application programs to distinguish them from system programs, which are used to control the internal operations of the host processor.
Most application programs are written to an application programming interface or API which assumes a specific communication protocol.
As networks have grown, and particularly as local area networks have come into widespread use, many organizations have ended up with confederations of individual networks running different networking protocols. This heterogeneity has arisen for a number of reasons. Organizations with different kinds of networks may merge or one may be acquired by another. Individual departments within a single organization may acquire their own hardware and software and create their own local networks without regard to what other departments in the same organization may be doing.
It has become commonplace for a single organization to have dozens of networks running as many as four or five different networking protocols, including those identified above and others.
If a mismatch exists between the transport protocols assumed by an API for a company's application program and the transport protocols actually implemented in one or more of the networks on which the organization would like to transport the application data, effective use of the program is hindered.
The problems caused by transport "protocol mismatches" are likely to get worse as more and more organizations begin to communicate with each other through their computer networks to perform functions such as order processing or direct billing or to carry out cross-organization activities such as implementation of joint ventures or conduct of standards activities.
An organization needs the capability of writing an application once and having it run on different networks and being able to communicate with matching applications through heterogeneous networks.
In the absence of this capability, an organization has two choices. One choice is to rewrite the applications so they can run over a different transport protocol.
The other choice is to build application gateways to allow different applications with similar functions to communicate. For example, there exist application gateways to allow an electronic mail application associated with SNA to communicate with a similar application associated with OSI.
The main drawback to this approach is that each application gateway handles only one specific application. If an organization has N different networks, it would have to have N(N-1)/2 application gateways to achieve complete interoperability among programs running on the different networks. The cost of having programmers write all of the necessary application gateways makes the approach economically unattractive.
The capability to write an application once and have it run on different networks exists only partially today. Programs written to particular API's today may run across more than one type of network. For example, programs written to a NetBEUI (NetBIOS End User Interface) can run across either NetBIOS or IPX network protocols. Similarly, programs written to a XTI interface can run on TCP/IP or OSI networks. Even where an API allows access to multiple protocols, the programmer must be aware of the protocols that will be used when writing the program.
While better than nothing, this degree of flexibility is considered inadequate by many organizations, who would like to be able to choose application programs based solely on the functions they perform, not on the protocols they use.